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REMARKS 

This is intended as a full and complete response to the Final Office Action dated 
September 18, 2007, having a shortened statutory period for response set to expire on 
December 18, 2007. Applicants submit this response to place the application in 
condition for allowance or in better form for appeal. Please reconsider the claims 
pending in the application for reasons discussed below. 

Claims 1-44 are pending in the application. Claims 1-44 remain pending 
following entry of this response. 

Specification Objections 

The Examiner objects to the specification suggesting that it fails to provide proper 
antecedent basis for the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 
608.01 (o). Specifically, the Examiner states that the limitation "to create a third column 
that..." is recited in claims 1, 22, and 43 is not supported in the specification of the 
disclosure. 

Respectfully, Applicants point the Examiner to Specification, fflj 3-7. These 

paragraphs provide an example where it would be useful to merge data from columns in 

separate database tables; specifically, a "Results Allergy A" table and an "Allergy A 

Results " table. In the example, both tables contain the same type of data, in that both 

contain names and address of patients, as well as contain this information "about an 

investigation concerning an allergy A which has been performed with respect to a 

multiplicity of individuals." The specification goes on to posit a scenario where: 

[a] pharmaceutical company wants to determine triggering factors for the 
allergy A. To this end, the pharmaceutical company would analyze all 
collected data from both tables. To efficiently analyze the collected data, it 
is desirable to merge both tables into a single table. 

Specification, ^ 4. In other words, the Specification begins by describing a scenario 
where it would be useful to take data from a first table and a second table, and merge 
them into a single, third table. To do so, data from a column in the first table is merged 
with data from a column in the second table; namely, in this example, columns from the 
first and second tables that contain patient names are merged and columns from the 
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first and second tables that contain addresses are merged. Data for each of the 

merged columns may be stored in a column in the single, third table. The Specification 

describes the structure of the single third table as follows: 

the database administrator could merge the columns "PatientName" and 
"Patient" into a column "Patient Name" and the columns "Address" and 
"Location" into a column "Patient Address" in order to provide a single 
resultant table "Allergy A Investigation." 

Specification, If 5 (emphasis added). Clearly, the description of merging the 

"PatientName" and "Patient" columns into a single column "Patient Name" provides 

support for a method step of "merging the first and second columns to create a third 

column that contains each data value stored in the first and second columns," as recited 

by the present claims. And the merging of the "Address" and "Location" columns 

provide an additional example. The Specification goes on to point out that: 

However, one difficulty when merging independently created database 
tables consists in identifying correlated columns in the database tables 
which are mergeable to create a meaningful merged result. 

Specification, 1f 6. To address this problem, Applicants specification goes on to both 

describe and claim techniques for identifying mergeable data in a first and second 

database column. Among other examples, the specification provides: 

... in response to user input, the first and second column or the at least 
two columns are merged into a single column. 

... if the correlation value 152 for two given columns exceeds a 
predetermined threshold, it is assumed that the two given columns are 
correlated and can potentially be merged into a single column 45. 

... a message is displayed to a user indicating the determined correlated 
columns. In one embodiment, the user can thus make a decision on 
whether to merge the determined correlated columns. Accordingly, in 
response to an appropriate input from the user, the determined correlated 
columns are merged. 

Specification, fflj 35, 45, 51 . Based on the foregoing discussion, Applicants submit that 
the specification provides more than adequate support for the limitation of the present 
claims objected to by the Examiner. Accordingly, Applicants respectfully request that 
this objection be withdrawn. 
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Claim Rejections - 35 U.S.C. 5 103 

Claims 1-44 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Sandler et al. {Sandler hereinafter) (US Patent No. 2003/0217033 A1, filed: May 17, 
2002) in view of Kaufman et al. (Kaufman hereinafter) (US 2004/0073565 A1). 
Applicants respectfully traverse this rejection. 

The Examiner bears the initial burden of establishing a prima facie case of 
obviousness. See MPEP § 2142. To establish a prima facie case of obviousness three 
basic criteria must be met. First, there must be some suggestion or motivation, either in 
the references themselves or in the knowledge generally available to one ordinary skill 
in the art, to modify the reference or to combine the reference teachings. Second, there 
must be a reasonable expectation of success. Third, the prior art reference (or 
references when combined) must teach or suggest all the claim limitations. See MPEP 
§ 2143. The present rejection fails to establish at least the third criteria. 

Regarding claims 1 , 22, and 43: 

Specifically, Sandler does not teach or suggest a "method for identifying 

correlated columns from database tables" that includes "determining correlation 

attributes for a first column and a second column from one or more database tables, the 

correlation attributes describing for each column at least one of the column and content 

of the column," as recited by claim 1. Claims 22 and 43 recite a similar limitation. 

Nevertheless, the Examiner suggests that Sandler discloses this limitation as follows: 

Fig. 18A, items 1806, and 1804, Page 17, [0235], lines 7-12; wherein the 
step of mapping which includes all of the values in field K1 1804 that have 
the same values in field F1 1806 corresponds to the step of determining 
the correlation attributes as claimed; wherein values F1 corresponds to 
the first column claimed; and wherein values in K1 corresponds to the 
second column claimed; 

Final Office Action, p. 4. The Examiner then relies on this same material to argue that 

Sandler discloses the claimed steps of "identifying similarities between the first and 

second column on the basis of the comparison," and "on the basis of the identified 

similarities, determining whether the first and second column are correlated," and "upon 

determining the first and second columns are correlated, merging the first and second 
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columns to create a third column that contains each data value stored in the first and 

second columns," as recited by claim 1. In fact however, the values in "field K1 1804 

that have the same values in field F1 1806" do not teach or suggest "correlation 

attributes" as suggested by the Examiner. Instead, Sandler provides: 

the field F1 1806 in table T1 1800 is mapped many-to-one to the field K 
1808 in the table TARGET 1802. To perform this mapping, all of the 
values in field K1 1804 that have the same values in field F1 1806 must be 
combined to provide a value for field F 1810 in table TARGET 1802. In 
this example, a SUM operation is used to combine the values from field 
K1 1804. 

Sandler, If 235. The values in the field "K1" are not correlation attributes of the values in 
the field "F1" at all; instead, the field values are simply the data values of records in the 
entered in the "F1" and "K1" columns of the "T1" table. More generally the material 
cited by the Examiner is an example of an "aggregation" operation disclosed in Sandler 
used to combine values in a table. As disclosed in Sandler, "[s]uch aggregation 
operations are used to represent many-to-one relations, and occur only after the table 
rule has been applied, to convert a combined table (which results from application of 
various fuse, link, and loop operations) into the target table." Sandler, If 234. Thus, the 
"aggregation operation" converts one table into another. The specific Example cited by 
the Examiner includes a table from Figure 18A with the following values: 



TableTI 


F1 


K1 


A 


1 


A 


2 


B 


3 


K 


4 


B 


5 



In this example, as part of the "aggregation operation" the repeated "A" values of "1" 
and "2" are summed to create an entry of "A" with a value of "3. Similarly, the repeated 
"B" values of "3" and "5" are summed to create an entry of "B" with a value of "8". No 
part of this process includes the claimed step of "determining correlation attributes for a 
first column and a second column from one or more database tables, as recited by 
claims 1 , 23. Further, nothing in this material discloses the claimed steps of "identifying 
similarities between the first and second column on the basis of the comparison," and 
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"on the basis of the identified similarities, determining whether the first and second 
columns are correlated." Instead, this material describes an "aggregation operation" 
used to process certain entries in a table that result from "loop, fuse, and link" 
operations. Accordingly, Applicants respectfully request that the rejection of claims 1, 
22, and 43 be withdrawn. 

Regarding claims 2 and 23: 

Claim 2 depends from claim 1 and further specifies a step of "determining 

whether the correlation value exceeds a predetermined threshold." Claim 23 recited 

similar limitation In rejecting this claim, the examiner suggests that Sandler discloses: 

[a step of] determining whether the correlation value exceeds a 
predetermined threshold (Page 2, [0018], lines 6 - 9; is above a 
predetermined threshold; Sandler). 

Final Office Action, p. 6. This passage provides: 

In general, in another aspect, the invention relates to a method for 
external checkpointing. The method includes initially communicating a 
data table and a log comprising entries of data table transactions to a 
subscriber; and communicating additional log entries to the subscriber 
when they are received. The method includes determining that the number 
of log entries is above a predetermined threshold, applying the log entries 
to the data table, and communicating the updated data table to the 
subscriber. 

Sandler, ^ 18. This description of "method for external checkpointing" that includes 
"determining whether that number of log entries is above a predetermined threshold" 
has no relationship whatsoever to the claimed subject matter. As is well known, 
"checkpoint" refers to a synchronization point between data files and log files. The cited 
passage describes transaction processing that includes executing log entries once the 
number of log entries reaches "a predetermined threshold." Clearly, the use of "a 
predetermined threshold" to determine when the number of log entries is above that 
threshold has nothing to do with the subject matter of "determining a correlation value 
indicating a degree of correlation between the first and the second column and 
determining whether the correlation value exceeds a predetermined threshold." The 
former is related to the number of entries in a log file, whereas the claimed limitation is 
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directed to a degree of correlation between a first and second column. Accordingly, 
Applicants respectfully request that the rejection of claims 2 and 23 be withdrawn. 

Regarding claims 6, 9, 1 1 , and 14: 

Claims 6, 9, 11, and 14 each depend from claim 1 and further characterize the 
correlation attributes. Claims 6, 9, 11, and 14 specify that the "correlation attributes" 
may be determined on the basis of: (i) metadata describing characteristics of the 
column (claim 6), (ii) statistical parameters associated with the column, (claim 9), (iii) 
ontological properties describing cognitive qualities associated with the column, (claim 
1 1 ), and (iv) measurement units associated with the column. Claims 27, 30, 34, and 35 
recite similar limitations, respectively. In rejecting these claims the Examiner cites to 
various portions of Sandler unrelated to the "aggregation operation" cited in the rejection 
of the underlying independent claim. Applicants submit that the isolated fragments cited 
by the Examiner fail to disclose the claimed characterizations of the "correlation 
attributes," as recited by these claims. Accordingly, Applicants respectfully request that 
the rejection of claims 6, 9, 1 1 , 1 4, 27, 30, 34, and 35 be withdrawn. 

Regarding claims 3-5. 7-8. 10. 12-13. 15-16. 24-26. 28-29. 31-33. and 36-37: 

Each of claims 3-5, 7-8, 10, 12-13, 15-16, 24-26, 28-29, 31-33, and 36-37 
depend from one of claims 1 or 22. Accordingly, for all the reasons given above 
regarding independent claims 1 and 22, Applicant submits that these dependent claims 
are allowable and respectfully requests that the rejection of these dependent claims be 
withdrawn. 

Regarding claims 17. 38. and 44: 

Sandler does not teach or suggest a "method for identifying correlated columns 
from database tables" that includes a step of "determining a degree of correlation 
between the at least two columns using the determined metadata and the analyzed 
content." Claims 38 and 44 recite a similar limitation. In rejecting these claims the 
Examiner again turns to the "aggregation operation" disclosed in Sandler used to 
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combine values in a column of a database table. Specifically, the current rejection 
provides: 

(Page 17 and 18, [0235] and [0251], lines 8 - 15 and 3 - 10; respectively, 
wherein the step of mapping by combining the same values in fields- 
corresponds to the step of determining the degree of correlation as 
claimed; wherein the "many-to-one" corresponds to the metadata claimed; 
wherein the values in the fields corresponds to the analyzed content 
claimed; and wherein the mapping after combining the values, for 
example: value of the field F 1802, corresponds to the degree of 
correlation claimed; Sandler); 

Final Office Action, p. 12. Candidly, the process of "combining the same values in 

fields" in no way discloses the step of "determining the degree of correlation" between a 

first database column and a second database column. Instead, the material describes 

adding up each number in one filed of a set of database records that share a value in 

another field of the set of database records. No "degree of correlation" is determined, 

calculated, or otherwise suggested by the "aggregation operation" disclosed in Sandler. 

Accordingly, Applicant submits that these independent claims are allowable and 

respectfully requests that the rejection of claims 17, 38, and 44 be withdrawn. 

Regarding claims 18-21 and 39-42: 

Each of claims 18-21 and 39-42 depend from one of claims 17 or 38. 
Accordingly, for all the reasons given above regarding independent claims 17 and 38, 
Applicant submits that these dependent claims are allowable and respectfully requests 
that the rejection of these dependent claims be withdrawn. 
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Conclusion 

Having addressed all issues set out in the office action, Applicants respectfully 
submit that the claims are in condition for allowance and respectfully request that the 
claims be allowed. 

If the Examiner believes any issues remain that prevent this application from 
going to issue, the Examiner is strongly encouraged to contact Gero McClellan, attorney 
of record, at (336) 643-3065, to discuss strategies for moving prosecution forward 
toward allowance. 



Respectfully submitted, and 
S-signed pursuant to 37 CFR 1.4, 

/Gero G. McClellan, Reg. No. 44,227/ 



Gero G. McClellan 
Registration No. 44,227 
Patterson & Sheridan, L.L.P. 
3040 Post Oak Blvd. Suite 1500 
Houston, TX 77056 
Telephone: (713)623-4844 
Facsimile: (713)623-4846 
Attorney for Applicants 
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